1994-1996 by Oberon microsystems, Inc., Switzerland.
All rights reserved. No part of this publication may be reproduced in any form or by any means, without prior written permission by Oberon microsystems. The only exception is the free electronic distribution of the education version of Oberon/F (see the accompanying
copyright
notice
for details).
Oberon/F module interfaces and their descriptions in particular may not be used in other works without written permission.
Oberon microsystems, Inc.
Technoparkstrasse 1
CH-8005 Z
Switzerland
Oberon is a trademark of ETH Z
rich, Switzerland.
Oberon/F, Oberon/L, "Oberon by Example", "The Oberon Tribune", "Oberon Developer Forum", and "Drag & Pick" are trademarks of Oberon microsystems, Inc.
All other trademarks and registered trademarks belong to their respective owners.
Helvetica
StdLinks.ShowTarget('From Applications')
Helvetica
StdLinks.ShowTarget('The Module')
StdLinks.ShowTarget('Subsystems and')
StdLinks.ShowTarget('Device Drivers')
StdLinks.ShowTarget('User Interaction')
StdLinks.ShowTarget('Message Records')
StdLinks.ShowTarget('Garbage Collection')
StdLinks.ShowTarget('The Architect')
StdLinks.ShowTarget('From White')
Helvetica
StdLinks.TargetDesc
From Applications
Helvetica
HostPictures.StdViewDesc
Geneva
Application
Library
y Extension
u Framework
The Module
Helvetica
Controllers
Dialog
Views
Models
Stores
Files
Fonts
Ports
Domains
Properties
Containers
Controls
Services
Strings
Dates
Library
Framework
Converters
Subsystems
Helvetica
Subsystems and
Device Drivers
Geneva
RS232Rider
RS232Rider
RS232Carrier
NetRider
NetRider
NetCarrier
Geneva
BinMapper
ASCIIMapper
NetRider
NetRider
NetCarrier
Geneva
mapper
rider
Binary
Mapper
ASCII
Mapper
RS232Rider
NetRider
Binary
on RS232
ASCII
on RS232
Binary
on net
ASCII
on net
User Interaction
Geneva
model
controller
controller
Geneva
window
child window
text view
text model
graphic view
frame for text view
frame for (
graphic view
frame for (
graphic view
graphic model
graphic view
Message Records
Geneva
front path
target path
front focus
target focus
front window
bottom window
focus hierarchy
Geneva
model
frame
frame
frame
frame
model notifies its
views with a model
broadcast
views notify their
frames with view
broadcasts
Garbage Collection
The Architect
Geneva
Fonts
Stores
Models
Views
Controllers
From White
Oberon/F
The Concepts Behind Oberon/F
Copyright Notice
Contents
Applications
Frameworks
Components
Module
Hierarchies
Oberon/F
Subsystems
Global
Modules
Device
Drivers:
Carriers,
Riders,
Mappers,
Directories
Interaction:
Models,
Views,
Controllers
Message
Records
Garbage
Collection
Prerequisite
Safety
Architect's
Tools
Trade
White-Box
Frameworks
Towards
Black-Box
Frameworks
The first three sections of this chapter serve as an introduction to and overview over the design of Oberon/F. They are recommended reading for anyone who wants to get a deeper understanding of Oberon/F.
The next three sections give an in-depth description of several important concepts of Oberon/F. It is recommended that the reader already has gained some experience with Oberon/F before reading these sections; e.g. by reading the tutorials, or by working through the Obx examples.
The last three sections give a more theoretical background to some fundamental concepts on which Oberon/F rests.
From Applications to Frameworks and Components
An application framework is a semi-finished product. It implements generic parts of an application, i.e. parts which are the same - or at least similar - for every similar kind of application. For graphical user interfaces, these are mainly the management of windows, menus, printing, and other generic services. A programmer need only provide the rest of the application, namely the parts which are unique to it. This is termed extending the framework.
In a component software environment, framework extensions are components which can be loaded dynamically; they are not pre-linked into the framework. From a user's perspective, components are represented e.g. as menus or as document parts. From a programmer's perspective, components are modules or whole subsystems.
One potential benefit of using an application framework becomes immediately clear when we look at the source code for a graphical user interface (GUI) program that was written completely from scratch: it can take pages of code merely to initialize and open a window with its menus. Frameworks dramatically reduce the effort to write GUI applications by eliminating such chores.
In contrast to subroutine libraries, a framework allows much more than mere code reuse. It defines a structure for the framework's extensions, i.e. a blue-print which can be followed when creating a new extension component.
The structure of a framework extension is predefined by the framework's interfaces. Extensions must provide suitable implementations of these interfaces. The interfaces of a framework, their documentation, and the default code contained in the framework are the means by which a framework defines a prefabricated structure for future extension components.
In contrast to classical subroutine libraries, a framework is not only called by some application, but the framework also calls the application. A call from framework to application (i.e. extension component) is called an "upcall". Why this term is justified can be seen in the following diagram, where an arrow describes who calls whom:
Picture a : Typical Control Flows in a Subroutine
Library and in an Application Framework
Sometimes this is called the "Hollywood Principle" of object-oriented programming, which says:
Don't call us, we call you.
In reality, the situation is more involved. An extension sometimes does call the framework, an extension can itself be extensible and act as a more specialized framework, and several extensions may work together "sideways" as well. These potentially confusing possibilities underline the importance of structure, which is afforded by the framework. For large software systems, a good system structure (sometimes called a system design or system architecture) becomes far more important than the issue of code reuse, for example. In practice, a bad system structure quickly limits extensibility and integration.
Oberon/F is a component framework because it can be extended at run-time by new components. Consequently, there is no single application in the traditional sense anymore. Rather, there is only an ever growing collection of interacting components. The main challenge in the design of a component framework is how to support close integration of components, while at the same time ensuring cooperation and robustness.
The Module and Type Hierarchies of Oberon/F
Oberon/F is decomposed into a hierarchy of modules which provide systematically constructed abstractions. Features which are not used can be ignored ("progressive disclosure").
At the "bottom" of Oberon/F, the differences between hardware platforms are hidden as much as possible. At the "top", the differences between user-interfaces are hidden as much as possible. For example, there are no assumptions built into Oberon/F about the underlying window system, e.g. whether it provides overlapping or tiling windows. In fact, the abstraction of a window is just as absent from Oberon/F as the abstraction of an application.
Because Oberon/F constitutes a layer between the operating system and the application, it must be efficient. This not only applies to speed, but also to memory and disk requirements. However, the efficiency of a particular Oberon/F implementation is necessarily dependent on the quality of the underlying operating system and hardware.
Oberon/F interfaces are safe, i.e. an Oberon/F application which doesn't use the low-level facilities of module SYSTEM is type-safe. A module which is type-safe may only create local damage, even if it contains arbitrary errors. In particular, it cannot destroy invariants guaranteed by other modules. This bug containment is especially relevant if components of differing origins are combined in a single document.
A central aspect of Oberon/F is its extensibility. It is possible to extend most major Oberon/F data types, in order to add new functionality to the existing system. Many basic services can be replaced or supplemented by new customized versions, in a way that existing applications can make use of the new facilities. To reach this degree of extensibility and configurability, module interfaces are constructed in a systematic way, which is described in this chapter.
For the design of the Oberon/F interfaces, several principles have been followed:
Simplicity
It should be easy to learn and easy to use the module interfaces.
Safety
Interfaces should be safe, i.e. the integrity of the system must be guaranteed as long as only public interfaces are used; even if they are used in arbitrarily incorrect ways.
Interfaces as Contracts
Interfaces should be specified in a sufficiently precise way, using preconditions, postconditions, and sometimes equivalent source code fragments. Violations of preconditions or other programming errors should be detected and flagged as early as possible.
Portability
The services provided by public interfaces should be implementable on every modern personal computer or workstation.
Separation of User Interface and Program
User interface and program should be coupled as loosely as possible. A program should not be burdened with handling details of the user interface. It should be possible to modify user interfaces without changing a program's source code, and without recompilation.
Hiding Global Resources
Global resources (e.g. files, windows, menus) should not occur in public interfaces whenever possible. The is because different platforms and emerging compound document standards (OLE, OpenDoc) sometimes have their own strategies of how to manage and arbitrate the use of global shared resources. There should be as little interference with such strategies as possible.
Picture a: Module Hierarchy of Oberon/F
The diagram above shows the module structure of Oberon/F. A small labeled rectangle denotes a module. A module which (may) import another one is placed higher in the hierarchy. A large labeled rectangle denotes a complete subsystem, consisting of several related modules.
The hierarchy is structured into three layers. At the bottom, the library layer contains modules which provide a number of unrelated services:
Services provides low-level system services. Currently, it mainly provides actions, i.e. atomic commands which can be executed in the background.
Meta provides access to run-time type information (metaprogramming).
Math is a collection of mathematical functions.
Strings is a collection of string operations, plus conversions between numbers and strings.
Dates provides date and time data types, operations on these data types, and conversion routines.
Dialog provides various facilities for the interaction with the user, e.g. standard dialogs for file opening and closing, and for presenting error messages.
Files provides abstract files of a hierarchical file system, and readers and writers as access paths to files.
The framework layer contains services for display, input, document storage, and document-centric user interactions:
Fonts handles font identification, font measurements, and font lookup.
Ports provides abstract display ports, riders as access paths to ports, and frames as port mappers.
Domains defines a grouping construct for arbitrary objects. This construct is called a domain. As an example, every displayed document belongs to one domain. Most message broadcasts are restricted to one domain.
Stores defines the base type for all extensible storable objects, and file mappers for the externalization and internalization of stores.
Converters provides a mechanism for the conversion between file formats and stores.
Models defines a base type for the representation of storable data, as well as operations for the management of model modifications.
Views defines the central abstraction of a view, which provides presentation of a model.
Controllers defines the controller abstraction. A controller supports user interaction with a view and the view's model.
Properties defines the property abstraction. Properties allow to modify a view's attributes in a generic, and possibly non-interactive way.
Containers defines model, view, and controller for general containers, i.e. for views which may contain a variable number of arbitrary other views. This fundamental abstraction allows to hide the major differences between the OLE and OpenDoc user interfaces.
Controls gives a property interface to controls, i.e. to views such as buttons, check boxes, text entry fields, etc.
Finally, the application layer provides three standard subsystems: a text subsystem, a subsystem for forms (e.g. dialogs), and a subsystem which constitutes the development environment. Miscellaneous other modules in the application layer are not shown here.
Modules which are not of general interest or do not provide portable abstractions are called private. Their interfaces may not be portable, may not be documented, or may change arbitrarily between releases. Most names of private modules start with the prefix "Host" or "Std", which are reserved subsystem prefixes. An implementation may contain further private global modules like Kernel, Loader, Windows, or Documents.
Private modules are not shown in the above module diagram. Some of them may be described in the host-specific documentation for a given Oberon/F implementation, but should not be considered as parts of Oberon/F proper. This also holds for interface modules to the host platform; which may be provided as well, in order to allow direct access to features particular to the given platform.
An Oberon/F developer can use his own unique module name prefix for the module names of his project(s), in order to eliminate name clashes with module names of other developers. Oberon microsystems acts as a clearinghouse for such name prefixes, by providing a prefix registration service.
Subsystems and Global Modules
A potential problem for any independently extensible system is the name space pollution problem of extensions: if two vendors would sell different extensions for Oberon/F, but under the same name, a conflict could arise: the two extensions could not be used on the same machine at the same time, since Oberon/F wouldn't know which was which.
It is possible to resolve such a conflict by appropriate renaming; however this requires that all clients of the renamed extension are updated accordingly; often an impossible task.
A better solution is to avoid conflicts right from the start, by giving extensions globally unique names. This can be done by providing a central registration service for all extensions, in this case for all Oberon/F modules. To reduce the administrative overhead of such a solution, Oberon microsystems opted for a two-level strategy: Oberon microsystems only registers subsystem names for a small fee, guaranteeing that such a name hasn't been registered yet. The buyer of a subsystem name should then guarantee that no two modules in this subsystem have the same name, where subsystem simply means a collection of modules. Typically, a subsystem also corresponds to a project.
This strategy is realized by a naming convention: every module name may contain a subsystem name as prefix, e.g. TextModels and TextViews belong to subsystem Text. The subsystem name begins with the first letter of the module name, and ends at the transition of a lower case letter (or digit) to an upper case letter. If no such transition exists, e.g. as in Files or Views, the module is called a global module, and belongs to the default subsystem called System. Global module names are reserved by Oberon microsystems. However, global module names may also be used by anyone for modules which are not meant to be published, i.e. where module name clashes can be resolved locally (e.g. when doing strictly in-house development and use of software) or where they are not critical (e.g. in a teaching environment).
This naming convention is technically supported by Oberon/F in that its compiler, linker, loader, and other development tools use subsystem names to determine where to fetch (or put) symbol files (or code files), as well as documentation and resource files. In the Oberon/F directory, there is one directory for every subsystem. The standard subsystems are Dev, Form, Host, Mac (Mac OS), Obx, Std, System, and Text. The directory names must be identical to the subsystem names. A typical subsystem directory itself contains five directories: Code, Docu, Mod, Rsrc, and Sym.
- the Code directory contains the code files of all modules in the subsystem, one file per module
- the Docu directory may contain a programmer's reference for several or all modules in the subsystem, one file per module
- the Mod directory may contain the sources for several or all modules in the subsystem, one file per module
- the Rsrc directory may contain data files ("resources") for the whole subsystem, currently these are mostly Strings files, one per subsystem; and possibly some files containing forms (dialogs).
- the Sym directory contains the symbol files for several or all modules in the subsystem, one file per module. A symbol file is a binary representation of a module's interface.
In addition, there is typically a Map file in the subsystem directory, which leads to various documentation texts, e.g. one file per module in the Docu directory. Furthermore, a file Guide in the Docu directory is the user manual for this subsystem, and a file Flyer in the same directory is a product description.
The Oberon compiler consumes program sources (usually the one displayed in the top window) and symbol files. A symbol file for module SubsystemModule is looked up as Subsystem/Sym/Module. The code file produced by the compiler is registered as Subsystem/Code/Module.
Windows:
The file extension of a symbol file is ".osf" (Oberon Symbol File).
The file extension of a code file is ".ocf" (Oberon Code File).
The browser (i.e. Info->Interface) looks up a symbol file for SubsystemModule as Subsystem/Sym/Module.
The reference tool (i.e. Info->Source and Info->Documentation) look up Subsystem/Mod/Module, and Subsystem/Docu/Module, respectively.
Note that files are only looked up, but not searched: a file's location is strictly determined by the module name (including the subsystem prefix) and by the kind of file to be looked up. If the file isn't at the expected location, lookup fails; no further search is performed.
The only exception to this rule occurs with global modules. Their code files are always placed in the Code directory in the Oberon/F directory. Their symbol files are always placed in the Sym directory in the Oberon directory. However, if the lookup of either a code or a symbol file of a global module fails, another attempt is made to open the file in System/Code or System/Sym, respectively.
If one of the development tools tries to register a file (e.g. a symbol file) in a directory which doesn't exist, the directory is created. The user is asked whether this should be done, or whether the command should be aborted instead.
Windows:
On file systems with restricted file name length (8 characters on Windows 3.1 or Windows for Workgroups), the module names are truncated accordingly. It is the programmer's responsibility to choose the module names such that the resulting file names differ. If files are transferred between a restricted and a less restricted file system (e.g. from Windows 3.1 to Windows NT or Mac OS), the file names must be adjusted.
Collecting all files of a subsystem in one subdirectory is a natural way to organize projects. Since subsystems are often the "unit of extension", it makes sense to use a corresponding subdirectory as the "unit of distribution". In particular, this makes installation trivial: copy the subdirectory into the Oberon directory, and you're done. To deinstall a subsystem, simply delete its subdirectory.
Note, however, that this only works if (mutable) data files are kept away from these subdirectories; otherwise deinstallation would result in a loss of data.
Device Drivers: Carriers, Riders, Mappers, and Directories
This section describes the strategy which is used for modeling device drivers in Oberon/F, as well as data structures which can be accessed in a similar way as devices, e.g. texts.
Access to a device's data passes through two different objects: a rider and a carrier. A carrier represents a data container, e.g. a file or a pixelmap. Several access paths may be open on one carrier at the same time. This n:1 relationship gives rise to the separation of carriers and riders, where a rider represents one access path to its carrier.
The implementation of a rider must have intimate knowledge about the implementation of its carrier, e.g. a file rider must know about the disk sector corresponding to its current position. Thus an extension of a carrier usually requires an appropriate extension of its rider as well. As a consequence, a rider is generated by its carrier, which provides an allocation function for this purpose.
A rider provides primitive input/output operations, the so-called bottleneck interface. These primitives can be used to build more complex operations which form a higher-level abstraction, possibly even an application-specific abstraction. Such a higher-level abstraction will generally be called a mapper in this documentation. A mapper contains a rider as a link to the carrier. During their use, mappers and riders form 1:1 relations, i.e. pairs.
Picture b: Carrier-Rider-Mapper Separation
In contrast to riders, mappers know nothing about a carrier's implementation, and thus can be extended independently. This independence means that every mapper may be used on any compatible rider, without the need to implement all combinations of mappers and riders individually. This situation is shown below for the hypothetical case of riders that operate on serial carriers like RS232 links or networks:
Picture c: Extensibility in two Dimensions
As was explained earlier, Oberon/F generally doesn't allow the extension of concrete types. Mappers are exceptions to this rule, because by their very nature they create or interpret fixed external representations, e.g. number formats on screen or the representation of binary data on a file. Apart from possible optimizations for efficiency reasons, this fixed external representation practically defines the complete behavior of a mapper. Mappers and message records are the only exported concrete types in Oberon/F.
If concrete types are not exported, how can objects of such types be obtained? For this purpose, a module which exports an interface type also provides a so-called directory object, accessible through a global variable. Such a directory provides functions to allocate new objects, and often also procedures for looking up objects by a given key (this property, although not always available, led to the generic term "directory"). For example, a file directory provides functions to create new empty files, as well as to look up existing files by name.
Directory objects are powerful facilities, since they can be replaced at run-time; usually this is done during the boot configuration process. This makes it possible to add and integrate extended services at run-time (i.e. new concrete types), which allows a system to grow in a controlled manner.
To summarize:
- Carrier container for data
- Rider access path to carrier, bottleneck interface
- Mapper creates or interprets external data formats using a rider as link to a carrier
- Directory facility for generating or for looking up objects of concrete types
User Interaction: Models, Views, and Controllers
Oberon/F supports storable objects, i.e. objects which can be stored to and loaded from non-volatile carriers. Such objects contain arbitrary persistent state (data stored in a non-volatile way, e.g. on disk). For this purpose, a type Store is provided, which is the base type of all storable types. Stores are externalized on and internalized from files. Module Stores provides readers and writers, which are file mappers that implement a binary encoding of Oberon values like characters, integers, sets, or of complete stores. A store uses these mappers to read or write its internal data, which possibly may contain other stores as well, i.e. stores can be embedded hierarchically.
For interactive applications, three different extensions of stores are predefined by Oberon/F: models, views, and controllers. This seperation is known as the MVC separation, originally developed for Smalltalk at Xerox PARC (M for Model, V for View, C for Controller).
Picture a: Model-View-Controller Separation
A Model is a store that contains data which should be presented visually, e.g. a text (sequence of characters plus font attributes), or a graph (set of graphical objects plus pen attributes), etc.
A model is presented by a View. A view maps the model's contents into a rectangular display area, using frames as mappers to ports (e.g. screen ports or printer ports). Frames are also the input channels for mouse and keyboard actions.
Several views may present the same model simultaneously, e.g. there may be two views presenting different parts of the same text, or a list of numbers may be shown as a table and as a bar chart simultaneously.
Views are extended stores, and can thus be embedded in other stores, e.g. other views, or in models. The root of such a hierarchy is called a document. A document corresponds to a file, and is the root object displayed in a window.
A view may also perform user interaction. However, complex applications delegate this task to another object called a Controller. A controller may further delegate the actual operation to an operation, which is an object that specifies an invertable operation on a view or its model, i.e. it supports the undo feature.
Picture b Document Example
The example above shows the situation where two windows display a document with a text view, where the text contained in this view contains a graphic view. One of the windows is the main window, the other a child window of the same document. Child windows show all or part of a document's view hierarchy. The topmost view in a window is independent of its corresponding views in other windows; i.e. their sizes, scroll positions, and other view attributes may differ. They only share the same model.
If a model contains a view, this view is shared by all views (each in its own window) displaying the same model. However, for each window there exists one frame on this shared view. Thus there may be as many frames on any view as there are windows on this document.
The outlined scheme has the effect that a document is a store hierarchy (not necessarily a tree, but a DAG, i.e. a directed acyclic graph), and that a window is a frame hierarchy (always a tree) which mirrors a subset of the store hierarchy. There are as many frame trees for a store hierarchy as there are windows displaying the same document.
To summarize:
- Store base type of all storable objects
- Model data representation
- View data presentation
- Controller interaction
- Frame user input / display output mapper
Message Records
One of the most fundamental language constructs of Oberon are procedures. A procedure combines several statements into one more powerful entity, which can be used as a statement itself, e.g. to form even more powerful procedures.
In order to support object-oriented programming, procedures may be called indirectly via an object. This indirection leads to different actual procedures being called, depending on the object's dynamic type. Procedures which behave in such a polymorphic way are called type-bound procedures (or methods).
With any collection of similar procedures, it is theoretically possible to combine them into one procedure with an additional parameter. This parameter tells which member of the collection is selected when the procedure is called. As an example, consider the following procedures:
PROCEDURE (obj: Object) Show
PROCEDURE (obj: Object) Hide
These procedures can be combined into one procedure
PROCEDURE (obj: Object) Handle (show: BOOLEAN)
This procedure internally selects a Show or Hide behavior based on the additional parameter.
Such a combination becomes problematic, however, if the parameter lists of the different procedures are different, e.g. if the above procedure should be combined with
PROCEDURE (obj: Object) Select (from, to: LONGINT)
A solution to this problem is to pass a record as parameter to the combined procedure. Records are extensible, thus all necessary parameters can be combined in a suitable record extension:
Message = RECORD END;
ShowMsg = RECORD (Message) END;
HideMsg = RECORD (Message) END;
SelectMsg = RECORD (Message) from, to: LONGINT END;
Such a record can then be passed to a general handler procedure, e.g. a type-bound procedure as in the example below:
PROCEDURE (obj: Object) Handle (VAR msg: Message)
This procedure can not only replace the procedures
PROCEDURE (obj: Object) Show
PROCEDURE (obj: Object) Hide
PROCEDURE (obj: Object) Select (from, to: LONGINT)
but also any other procedure bound to type Object. Internally, Handle uses type tests to determine the action to be taken, and type guards to access the particular parameters (i.e. the record fields of msg). The Oberon WITH statement is a convenient combination of type test and guard:
Such a universal handler procedure is a simple and very general construct, but inconvenient and error-prone. The signature of a handler procedure reveals very little about what the procedure actually does, and the compiler cannot tell if message record fields have not been set up correctly. Thus, Oberon/F generally uses distinct procedures for distinct operations.
However, handler procedures can be convenient under special circumstances, namely when a procedure call must be applied to a large number of objects (broadcast of a message), or when the called object lets some other object do the work for it (forwarding of a message).
In these cases, the number of normal procedures would have to be multiplied, e.g. there would have to be a BroadcastShow procedure in addition to the Show procedure, a BroadcastHide procedure in addition to the Hide procedure, etc. This is inconvenient, because it results in bloated interfaces, and because broadcast procedures typically all work exactly the same way internally, i.e. one Broadcast procedure should be sufficient in principle.
For these reasons, the concept of universal handlers has been used in Oberon/F where this was most appropriate, i.e. where broadcasting or forwarding are used extensively. In the following paragraphs, these places are introduced.
When a user types a key, presses a mouse button, or executes a menu command, these events must be communicated to the appropriate view. Such a view is called a focus view. Views are contained in documents, and documents are displayed in windows. In most user interfaces, one of these windows is the front window (i.e. the focus window), and interactions occur with this window. A window can contain a whole hierarchy of views, thus one of them must be defined as focus.
Events like the ones described above are communicated by sending appropriate controller messages to the focus view (i.e. edit messages, scroll messages, etc.). Theses messages are not sent directly to the focus view, but are passed through the whole view hierarchy until they reach the focus. This makes it possible for a view to filter out (or to perform some other modification on) a message when desired, before it is passed to one of the embedded views.
In fact, Oberon/F does not even know which view currently is the focus. Instead, it sends messages to the focus window's document, from where it is forwarded along the focus path until it reaches the focus view. Every view which receives a controller message can decide on its own whether it wants to forward the message to one of its embedded views, or whether it wants to interpret the message itself. In the latter case, it is the focus view by definition!
Controller messages are forwarded throughout a hierarchy of views, thus they are appropriate candidates for a general forward procedure and for a handler procedure as outlined earlier.
The focus view either handles a controller message itself, or it sends it to a controller object for this purpose. If the message's type is not known, it should simply be ignored, in order to allow for future extensions.
Since in Oberon/F the same document can be shown in several windows simultaneously, every view may be visible several times simultaneously. Thus it is more precise to speak about the focus frame, instead of the focus view. Accordingly, a focus message is sent along the focus window's frame tree, instead of directly along the document's view hierarchy.
Although most interactions are performed with the front window, this is not always the case. Sometimes, two windows are involved in an interaction: a dialog and a document window. As an example, the document window may contain a text view, while a "Find & Replace" dialog may lie in front of the document window. In this case, typing is routed to the dialog, while the find and replace commands operate on the document window.
To support such a situation, Oberon/F defines two foci: a target focus (in the document window) and a front focus (in the dialog box). Every controller message is sent to exactly one of them.
Picture a: Simplified Example of Focus Hierarchy
When a controller message has arrived at its focus view, it may cause some effect there. A paste message may cause the clipboard's contents to be inserted into the focus view's model, for example. Afterwards, all views which display this same model must be updated, such that they show the new situation correctly. Oberon/F realizes this change propagation by sending a so-called model message to all affected views. This is an example of a message broadcast, and thus the second place where a general message handler is used in Oberon/F, in this case a handler for model messages. Model messages are not forwarded along a specific frame path, but rather sent to all affected views, using a Broadcast procedure.
Unfortunately, there may not only be several views for the same model, but also several frames for the same view, because several windows may be open simultaneously on the same document. This requires that after a model modification, the change propagation must be performed in two steps: from the model to each affected view, and then to each affected frame. This is realized with a second broadcast mechanism, this time for so-called view messages.
Picture b: Concept of Two-Level Broadcast
All in all, there are only a few places where universal handler procedures and extensible message records are used in Oberon/F, otherwise type-bound procedures are applied.
Garbage Collection as a Prerequisite for Safety
Extensible programs are never frozen, and thus there is no programmer who can know the whole software environment in which his particular piece of software will operate eventually. Software components can be tightly integrated, which means that several extensions may access the same data structure simultaneously, provided that this data structure is exported. Unfortunately, this also means that no programmer can know for sure whether this data structure is also referenced by someone else. This raises the question of when to deallocate a data structure, and by whom.
Many programs contain errors which cause some data structures to remain in memory forever, although they are not referenced anymore (memory leaks). Since memory is only finite, such programs may crash after running for some time.
On the other hand, if memory is deallocated too early, i.e. when it is still being referenced by someone, it may be re-allocated by someone else (dangling pointers). This is even worse than memory leaks, because several variables then use the same memory location to store different values. This is an error which has the character of a time-bomb: its effect may become manifest (often as a violent crash) much later than the error actually occurred, and at a seemingly unrelated place. This lack of locality makes such errors extremely hard to find.
The problem is so severe that it has spawned a whole industry providing tools to deal with it, with limited success.
The problem is hard for closed programs, i.e. programs whose source code is completely accessible to a programmer. But for independently extensible programs ("open systems"), these problems increase exponentially, since the cause of a crash may be any of the loaded extensions, whose internals are not known. For example, a compound document is only as reliable as the weakest component used in this document.
Traditional solutions to such safety issues are not applicable here: usual hardware protection schemes prevent exactly the kind of tight integration which is necessary for compound documents, and which is essential for efficiency.
The root of the problem is that in an open world, no one knows the whole program (since this concept doesn't exist anymore), and thus no one knows when memory can be deallocated safely.
Oberon doesn't have this problem at all: it leaves memory reclamation to a trusted system service, instead of burdening the programmer with explicit deallocation. In essence, such a garbage collector tries to prove for every memory block that it is not being referenced anymore. If the proof succeeds, it gives the block free for future use.
Garbage collection is not a feature of object-orientation. However, for component software it is an indispensible feature.
The Architect's Tools of the Trade
The architecture of a software system is the most difficult thing to get right, and the most expensive thing to get wrong. While code reuse is often discussed and sought after in order to save time and money, it is less obvious that architecture reuse is a much more important issue. If the architecture is flawed, the implementation and maintenance efforts can be dramatically increased, and the life-time of the product can be considerably shortened.
In fact, the purpose of a framework is mainly to define a suitable software architecture in a particular application domain, e.g. editors with graphical user interfaces.
A software architecture should be a structural backbone on which every programmer can rely. If a programming language allows to express architectural decisions explicitly, it becomes a most powerful computer-aided software engineering (CASE) tool, because a compiler for the language can verify the conformance of a program with its underlying architecture. The more it can check at compile-time, the better.
Programming languages differ in the degrees to which their constructs can express architectural decisions. In this respect, Oberon is one of the most powerful languages available today. Oberon provides several facilities to define the static structuring of a program; these facilities are essential tools for the software architect.
The largest structural unit is the compilation unit, a module. Modules define visibility boundaries (for information hiding). What is inside a module (i.e. constants, variables, types, procedures) cannot be seen (i.e. used, called, or modified) outside of this module, except if it is exported explicitly by the module. The exported items of a module are called its interface. A module may import the interfaces of other modules. Modules combine items which together form an abstraction, e.g. the abstraction of a file system. Such an abstraction usually entails not only one abstract data type or class, but a whole ensemble of related object types, as well as constants, global variables, and subroutines.
In Oberon, all software is composed of modules, whether it is an operating system, a framework, an extension component, or a tool. What is considered the operating system is thus not so much a technical issue, but more a matter of convention. Calls between modules are just normal procedure calls, there are no such things as special kernel calls or similar special constructs.
In systems which are not written entirely in Oberon, platform-specific language extensions may be provided, with the sole purpose of interfacing to foreign software, e.g. to the host operating system. Such language extensions must be optimized for the given host system, thus they are not portable and are not considered part of the language proper. Their use is normally limited to a few modules of a program.
The availability of a module construct is one of the major advantages of Oberon compared to most other current object-oriented programming languages.
An Oberon program can be described in terms of its module graph. This is a directed acyclic graph which shows who imports whom. Calls along an edge of such a graph are upcalls, while calls in the opposite direction are normal subroutine calls:
Picture a : Example of a Module Graph
Modules combine items which are related, e.g. several object types which work together to perform some task. The interfaces between modules should be kept as "thin" as possible.
As long as a module's interface (i.e. its exported items, as recorded in a module's symbol file) are not changed, its implementation can be modified freely, without making it necessary to recompile any other modules. A module's interface may even be extended in certain ways (e.g. by adding new procedures) without invalidating existing code. This is possible due to advanced compiler techniques which are applied in modern Oberon compilers.
Note: sometimes the problem of changing the implementation of a module without invalidating other code is called the "fragile base class problem". In the context of this text, we refer to it as the "syntactic fragile base class problem", in order to distinguish it from the more difficult "semantic fragile base class problem" described in the next section.
The second important static structuring facility of Oberon is its type system. Every variable has a type, which defines the set of values that the variable may contain, and the operations which are legal on this variable. Besides several basic types such as characters, integers, or sets, Oberon provides two kinds of structured types, namely arrays and records. Arrays are vectors of values with the same type, while records are tuples of values which may have different types. An array element is accessed via an index, while a record field is accessed via a name. Array elements and record fields may be records, arrays, or variables themselves. This makes it possible to combine types in a hierarchical way. Pointer types and procedure types are further powerful type constructs.
In order to support component-oriented programming, Oberon provides record extension and type-bound procedures. Record extension allows to declare one record type (sometimes called a class) as an extension of another record type. The extending type is compatible to the extended type (base type), which means that wherever a variable of the base type can be used, a variable of the extension type may be used as well. An extended type "is a" base type, but not vice versa.
A pointer type declares the record type to which it is bound, this is the so-called static type. However, the static type of a variable only defines a minimal requirement for the contents of this variable. Any extension of the static type can be assigned to the variable as well. Its true type is called the dynamic type of the pointer variable. The dynamic type is defined when a record is allocated, it cannot be changed afterwards.
Using record extension and pointers, polymorphic data structures can be built. An example of a polymorphic data structure is the list of windows managed by a window system: the list may contain document windows as well as dialogs. Both may be declared as extensions of a basic window type.
A type-bound procedure (sometimes called a method) is a procedure that is bound to a pointer (or its record) type. This means that depending on the pointer variable's dynamic type, a different procedure may actually be called. As a result, a pointer variable - which can appropriately be called an object now - may behave differently, depending on its dynamic type. Let us suppose that a window pointer has a procedure Close bound to it. Then a dialog box (which is an extended window) may simply close the window when this procedure is called, while a document window may first ask whether its contents should be stored on disk before closing.
Strong typing, strong modularity, and the integration of object-oriented programming techniques into a proven type system are among the important advantages of the Oberon language, making it not only an implementer's tool, but also a fundamental tool for the software architect.
From White-Box Frameworks Towards Black-Box Frameworks
In Oberon, a procedure may be bound to a record or pointer type. When a record type is extended, the extending type inherits all procedures bound to the base type. However, every inherited procedure may be overridden, i.e. the procedure's implementation may be redefined.
Overriding is a powerful feature, since it allows the replacement or modification of inherited (default) behavior. However, strict rules must be followed in order to use overriding correctly. Incorrect use leads to the so-called fragile base class problem, where the behavior of a base type cannot be modified anymore without breaking some of its extension types.
Note: we call this the "semantic fragile base class problem" in contrast to the less difficult "syntactic fragile base class problem" described in the previous section.
A general rule for a correct use of overriding is the following:
An overriding procedure must be compatible to the overridden procedure both syntactically and semantically.
Syntactic compatibility can be expressed in the language and checked by the compiler. Alas, semantic compatibility is more difficult to achieve. This is the cause of many design errors in class libraries.
Instead of using the term "overriding", it is much less misleading to use the term "extending". A procedure does not override or redefine another procedure, it much rather extends it, i.e. it does everything the base procedure does, plus something more. This immediately lets us conclude that the base procedure should be called in the extending procedure, with a super call. This guarantees that whatever the base procedure does, will also be done by the extending procedure, and in exactly the same way. Which is something we can expect of a semantically compatible procedure.
There is a special case where we don't want to call a base procedure in an extended procedure, namely when the base procedure provides a default behavior which can be re-implemented in a more efficient way. As an example, consider a file object which provides two procedures, one for writing a single byte, and another one for writing an array of bytes. Obviously, the second procedure can be implemented in terms of the first one. This may be reasonable to do as a default behavior. A particular file implementation however, e.g. for disk files, may increase performance considerably by re-implementing the same functionality directly.
If a base procedure is designed as a default procedure, its behavior must be specified completely (no hidden behavior), and everything needed for a re-implementation must be exported, i.e. must be available to possible re-implementers.
A special case of a default procedure is the empty procedure. For efficiency, an empty procedure should not be called by an extending procedure via a super call. Empty procedures are called hook procedures.
An empty procedure can be useful, because it forms part of its object's interface. If this is the only function of an empty procedure, we call it an interface procedure. An interface procedure is a procedure definition without a corresponding implementation, because the implementation cannot be provided where the interface is defined. The implementation must be delivered by the extensions instead. A procedure which is not an interface procedure is called a concrete procedure.
A data type which provides one or more interface procedures is called an interface type. Interface types are only interfaces, they have missing or at least incomplete implementations, and thus no variable of such a type can ever be used. Interface procedures must be overridden in any concrete extension type, and such a concrete type (i.e. a direct extension of an interface type) must not perform a super call. In Oberon/F, there is a convention to call the HALT statement in the body of an interface procedure, to detect any incorrect use.
Only variables of concrete types may be allocated and used. It is the programmer's responsibility to only allocate variables of concrete types.
Extending concrete types is dangerous, because a concrete type has much more specialized semantics than an interface type. This means that extensions of concrete types are likely to have changed (i.e. incompatible) semantics, instead of extended semantics as would be proper. In particular, complicated calling sequences can occur (upcalls, downcalls, super calls), resulting in very complex interactions of the side effects caused by these procedures. There is no way to specify (and thus to fully understand) such side effect interactions, except to publish all source code.
Frameworks which can only be used given their whole source code are called white-box frameworks. Experience shows that white-box frameworks suffer from two fundamental problems:
The first one is complexity: since interfaces cannot be separated from implementations in a white-box framework, the whole framework's implementation must be studied and understood by a programmer. This becomes virtually impossible for large and complex frameworks.
The second problem with the lacking distinction between interface and implementation is over-specification: every implementation detail must be considered part of the framework's specification, and thus cannot be changed anymore: the fragile base class problem mentioned earlier.
Let us summarize the problem with the extension of concrete types ("code inheritance"): A concrete procedure may internally execute statements, such as assignments or procedure calls, which modify the program's state. The exact nature and sequence of such modifications determine the behavior of the whole program, not only of the module or object to which the procedure belongs. In the presence of overriding and super calls, there exists no notation which allows to specify such effects precisely enough, except the program's complete source code. A program component whose complete source code has been published may not be modified anymore, since this might break existing extensions.
Since this was felt to be too restrictive, Oberon/F was designed more as a black-box framework instead: In general, concrete types cannot be extended in Oberon/F. This is achieved simply by not exporting them. Yet, type exension of interface types is used extensively, since this doesn't pose the described problems.
Abandonning code inheritance does not mean abandonning code reuse: Instead of reuse by inheritance, Oberon/F uses reuse by composition, e.g. a document is composed of views.
(.txt)